home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-157 < prev    next >
Encoding:
Text File  |  1988-12-01  |  13.8 KB  |  639 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                CMCC PERFORMANCE MEASUREMENT MESSAGE FORMATS
  7.  
  8.  
  9.                                   IEN 157
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.                              David Flood Page
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                        Bolt, Beranek and Newman Inc.
  27.  
  28.  
  29.                              50 Moulton Street
  30.  
  31.  
  32.                       Cambridge, Massachusetts 02238
  33.  
  34.  
  35.                                (617)491-1850
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.                              26 September 1980
  48.  
  49.      IEN 157                             Bolt, Beranek and Newman Inc.
  50.  
  51.  
  52.  
  53.  
  54.                              TABLE OF CONTENTS
  55.  
  56.  
  57.  
  58.  
  59.                                                                   Page
  60.  
  61.  
  62.  
  63.      1.  PREFACE                                                     1
  64.  
  65.  
  66.  
  67.      2.  INTRODUCTION                                                2
  68.  
  69.  
  70.  
  71.      3.  MESSAGE FORMATS                                             3
  72.  
  73.          3.1  CPU Idle Time - report type 8                          4
  74.          3.2  Packet delay - report type 9                           4
  75.          3.3  Gateway to gateway delay - report type 10              5
  76.          3.4  Bit Throughput - report type 11                        7
  77.          3.5  Queue occupancy - trap type 3                          8
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.                                      i
  107.  
  108.      IEN 157                             Bolt, Beranek and Newman Inc.
  109.  
  110.  
  111.  
  112.  
  113.      1.  PREFACE
  114.  
  115.  
  116.           This   document   describes  the  message  formats  for  the
  117.  
  118.      performance measurement reports and traps which are to  be  added
  119.  
  120.      to  the ARPA CMCC gateway monitoring messages.  It is an addendum
  121.  
  122.      to the Gateway Monitoring Protocol described in  IEN  131,  which
  123.  
  124.      should  be  consulted  first.  Processing for the new reports and
  125.  
  126.      traps will be added to the CMCC, and a document describing  their
  127.  
  128.      use will be issued later.
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.                                      1
  166.  
  167.      Bolt, Beranek and Newman Inc.                             IEN 157
  168.  
  169.  
  170.  
  171.  
  172.      2.  INTRODUCTION
  173.  
  174.  
  175.           The  message  types described here will be used in two ways:
  176.  
  177.      either experimentally, in  conjunction  with  message  generators
  178.  
  179.      used  to load the Catenet until something breaks, or regularly as
  180.  
  181.      are the other report types, to show how the Catenet  is  behaving
  182.  
  183.      at any time.
  184.  
  185.  
  186.           In  evaluating  Catenet performance, message generators will
  187.  
  188.      be required to load the gateways with traffic until  packets  are
  189.  
  190.      dropped,  the  delays  start  to  rise steeply, or the throughput
  191.  
  192.      saturates.  These conditions indicate  that  the  limit  of  some
  193.  
  194.      resource  has  been  reached.    These  message generators, whose
  195.  
  196.      implementation is yet to be defined, can be located in either the
  197.  
  198.      gateways, the CMCC program, or in other  internet  hosts.    When
  199.  
  200.      both  the CMCC program and the gateways implement the new message
  201.  
  202.      types, and message generators are defined  and  implemented,  the
  203.  
  204.      CMCC  will be able to find out how much traffic the gateways were
  205.  
  206.      processing, where the bottlenecks lie in the  Catenet,  and  what
  207.  
  208.      the accompanying delays were.
  209.  
  210.  
  211.           All the measures described here are cumulative from the time
  212.  
  213.      the  gateway  started.    The  CMCC  will,  by  keeping  suitable
  214.  
  215.      histories of the measures, be able to show shorter term values as
  216.  
  217.      required.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.                                      2
  225.  
  226.      IEN 157                             Bolt, Beranek and Newman Inc.
  227.  
  228.  
  229.  
  230.  
  231.      3.  MESSAGE FORMATS
  232.  
  233.  
  234.           All  gateway  monitoring  messages  consist  of  an Internet
  235.  
  236.      header followed by a monitoring  header,  and  then  the  message
  237.  
  238.      data.    A  monitoring  header,  as described in IEN 131, has the
  239.  
  240.      following format:
  241.  
  242.  
  243.            Bits   Contents
  244.              0    0 - Report or trap.
  245.                   1 - Negotiation message.
  246.  
  247.              1    0 - Report.
  248.                   1 - Trap.
  249.  
  250.            2-3    For a negotiation message:
  251.                   0 - DO
  252.                   1 - DONT
  253.                   2 - WILL
  254.                   3 - WONT
  255.                   For a report or trap: zero.
  256.  
  257.            4-7    Reserved.
  258.  
  259.           8-15    Report or trap type.
  260.  
  261.          16-31    For a negotiation message: report identifier.
  262.                   For a regular report: Sequence number.
  263.                   For a trap: data depending on trap type, i.e.
  264.                   this field is not part of the header
  265.                   for a trap message.
  266.  
  267.  
  268.      The five new message types are:
  269.  
  270.  
  271.        o  CPU idle time (which gives a measure of how heavily  the
  272.           gateway is loaded).
  273.  
  274.        o  Packet delay across a gateway.
  275.  
  276.        o  Gateway to gateway delay (round trip time).
  277.  
  278.        o  Throughput (bits).
  279.  
  280.  
  281.  
  282.  
  283.                                      3
  284.  
  285.      Bolt, Beranek and Newman Inc.                             IEN 157
  286.  
  287.  
  288.  
  289.  
  290.        o  Queue  traps (which signal when the occupancy of a queue
  291.           goes above or below a certain threshold value).
  292.  
  293.  
  294.  
  295.      3.1  CPU Idle Time - report type 8
  296.  
  297.  
  298.           CPU idle time gives an  idea  of  the  amount  of  time  the
  299.  
  300.      gateway  machine  is not doing useful processing.  The purpose of
  301.  
  302.      this is to find out when the CPU becomes saturated, which will be
  303.  
  304.      the case if the proportion of idle time becomes very small.   The
  305.  
  306.      report  consists  of  two  32-bit counts following the monitoring
  307.  
  308.      header:
  309.  
  310.  
  311.        1.  The amount of CPU idle time since the gateway  started,
  312.            in milliseconds.
  313.  
  314.        2.  The time since the gateway started, in seconds.
  315.  
  316.  
  317.  
  318.      3.2  Packet delay - report type 9
  319.  
  320.  
  321.           Packet  delay refers to the length of time a packet stays in
  322.  
  323.      the gateway.  The measurement of this delay  and  of  gateway  to
  324.  
  325.      gateway  delay  are  related: measurement of one begins where the
  326.  
  327.      other ends.  The model used here assumes that gateway  processing
  328.  
  329.      takes  place  in  three  parts: network I/O, queuing and routing.
  330.  
  331.      Implementation considerations will affect just where the  packets
  332.  
  333.      can  be timestamped on their way through the gateway, so that for
  334.  
  335.      some gateways it may be possible to stamp a packet at the network
  336.  
  337.      I/O level, while for others it may  not  be  possible  until  the
  338.  
  339.  
  340.  
  341.  
  342.                                      4
  343.  
  344.      IEN 157                             Bolt, Beranek and Newman Inc.
  345.  
  346.  
  347.  
  348.  
  349.      packet   enters  the  routing  processing.    This  specification
  350.  
  351.      therefore does not define where the boundary should lie,  but  it
  352.  
  353.      is important that together the measures account for all the delay
  354.  
  355.      that a packet will experience as far as the gateway is concerned.
  356.  
  357.      It  is  recommended  that the packet delay be made to refer to as
  358.  
  359.      large a fraction as possible of the time the packet spends in the
  360.  
  361.      gateway.  The report consists of two 32-bit counts and two 16-bit
  362.  
  363.      counts.  All delays are in milliseconds.  The format is:
  364.  
  365.  
  366.        1.  The total number of packets processed since the gateway
  367.            started (32 bits).
  368.  
  369.        2.  The total delay for all packets processed (32 bits).
  370.  
  371.        3.  The minimum delay experienced by a  single  packet  (16
  372.            bits).
  373.  
  374.        4.  The  maximum  delay  experienced by a single packet (16
  375.            bits).
  376.  
  377.  
  378.  
  379.      3.3  Gateway to gateway delay - report type 10
  380.  
  381.  
  382.           The measurement of  this  delay  and  of  packet  delay  are
  383.  
  384.      related:  see the first paragraph in the previous section.
  385.  
  386.  
  387.           This  report  could  be  something  of  an  interim measure,
  388.  
  389.      provided the gateways obtain radio  synchronizing  equipment  for
  390.  
  391.      measuring  the  one-way  delay directly.  However, currently only
  392.  
  393.      the round trip delay can be determined.  The report assumes  that
  394.  
  395.      gateways  will  use  some kind of tagged echo packets to find the
  396.  
  397.  
  398.  
  399.  
  400.  
  401.                                      5
  402.  
  403.      Bolt, Beranek and Newman Inc.                             IEN 157
  404.  
  405.  
  406.  
  407.  
  408.      round  trip  delay  to each of their neighbors, the tagging being
  409.  
  410.      used to identify specific packets.
  411.  
  412.  
  413.           The report format is a table  ordered  by  internet  address
  414.  
  415.      considered  as  a  32-bit  unsigned  integer.    Each table entry
  416.  
  417.      consists of an internet address followed by two 32-bit counts and
  418.  
  419.      two 16-bit counts.  The internet address is the neighbor  address
  420.  
  421.      for which this delay applies.  Of the 32-bit counts, the first is
  422.  
  423.      the cumulative total of the echo packets returned by the neighbor
  424.  
  425.      since  this  gateway  started,  and the second is the total delay
  426.  
  427.      experienced by those returned packets, in milliseconds.  The  two
  428.  
  429.      16-bit   counts   are   the   minimum   and  maximum  delays,  in
  430.  
  431.      milliseconds, for a single packet sent to the  neighbor.    There
  432.  
  433.      will  be  one table entry for each neighbor address, so that if a
  434.  
  435.      gateway is a neighbor on two networks then it will have two table
  436.  
  437.      entries.  There will be an entry for each such address  for  each
  438.  
  439.      neighbor that replies to the echoes, whether or not that neighbor
  440.  
  441.      is  a  routing  gateway. The table size may grow as new neighbors
  442.  
  443.      come up while a gateway is running, but it may  not  shrink;  the
  444.  
  445.      entry  for  a  gateway  that  stops  replying  will simply remain
  446.  
  447.      unchanged.
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.                                      6
  461.  
  462.      IEN 157                             Bolt, Beranek and Newman Inc.
  463.  
  464.  
  465.  
  466.  
  467.          The report format is therefore:
  468.  
  469.                  Internet address of first neighbor,
  470.                      lowest network number
  471.                  Total of echo packets returned by this neighbor
  472.                      (32 bits)
  473.                  Total delay experienced (32 bits)
  474.                  Minimum delay to this neighbor (16 bits)
  475.                  Maximum delay to this neighbor (16 bits)
  476.                  .
  477.                  .
  478.                  Internet address of last neighbor,
  479.                      highest network number
  480.                  Total echo packets returned (32 bits)
  481.                  Total delay (32 bits)
  482.                  Minimum delay for this neighbor (16 bits)
  483.                  Maximum delay for this neighbor (16 bits)
  484.  
  485.  
  486.  
  487.      3.4  Bit Throughput - report type 11
  488.  
  489.  
  490.           In  contrast  with  the packet throughput report type, which
  491.  
  492.      has its emphasis on the number of packets a gateway can  process,
  493.  
  494.      the  bit  throughput  report type focuses on how fast a gateway's
  495.  
  496.      network connections can accept or deliver data.  The report is  a
  497.  
  498.      table  of  pairs of 32-bit counts ordered by interface; the first
  499.  
  500.      count in each pair is the  cumulative  total  of  bits  processed
  501.  
  502.      coming  in at that interface, and the second is the output count.
  503.  
  504.      Interfaces are ordered as in  the  gateway  description  message,
  505.  
  506.      report  type  0.  There are two extra 32-bit counts at the end of
  507.  
  508.      the message: the first is the total  of  bits  dropped,  and  the
  509.  
  510.      second  is  the  time since the gateway started, in seconds.  The
  511.  
  512.      counts for the interfaces include all traffic at that  interface,
  513.  
  514.      including   control  traffic  and  messages  originating  at  the
  515.  
  516.  
  517.  
  518.  
  519.                                      7
  520.  
  521.      Bolt, Beranek and Newman Inc.                             IEN 157
  522.  
  523.  
  524.  
  525.  
  526.      gateway.
  527.  
  528.  
  529.          The format of the message is therefore:
  530.  
  531.                  Input count for first interface
  532.                  Output count for first interface
  533.                  .
  534.                  .
  535.                  Input count for nth interface
  536.                  Output count for nth interface
  537.                  Dropped count
  538.                  Time since gateway up
  539.  
  540.  
  541.  
  542.      3.5  Queue occupancy - trap type 3
  543.  
  544.  
  545.           This is a trap message which is sent by the gateway whenever
  546.  
  547.      a  queue  length  exceeds a threshold percentage specified in the
  548.  
  549.      trap request message, or when  the  occupancy  falls  below  that
  550.  
  551.      threshold  after  having been above it for some time.  If a queue
  552.  
  553.      is loaded such that the threshold occupancy is continually  being
  554.  
  555.      passed  in each direction, a large number of these traps would be
  556.  
  557.      generated in a short time.  To avoid this, there should  be  some
  558.  
  559.      minimum  time  interval  between successive trap messages.  It is
  560.  
  561.      left up to the individual gateway  implementors  to  decide  what
  562.  
  563.      this  time  interval  should  be; experience with using this trap
  564.  
  565.      type will probably suggest a reasonable value.
  566.  
  567.  
  568.           Note  that  this  replaces  the  earlier  Queue  full   trap
  569.  
  570.      described in IEN 131.  I believe that a percentage occupancy trap
  571.  
  572.      is  more  useful  because if a queue becomes full, the gateway is
  573.  
  574.  
  575.  
  576.  
  577.  
  578.                                      8
  579.  
  580.      IEN 157                             Bolt, Beranek and Newman Inc.
  581.  
  582.  
  583.  
  584.  
  585.      probably  already  dropping packets and the message is not useful
  586.  
  587.      as an early warning.  In any case, a queue full trap  is  just  a
  588.  
  589.      100% percentage occupancy trap.
  590.  
  591.  
  592.           The  DO  TRAP  message  for this trap type requires an extra
  593.  
  594.      piece of information: the percentage occupancy of the queue which
  595.  
  596.      is to trigger the trap.  This is expressed as  an  integer  in  a
  597.  
  598.      single byte following the report id field in the DO TRAP message.
  599.  
  600.      A  gateway should only use one value of this threshold at a time,
  601.  
  602.      so that a second DO TRAP message will supersede the previous  one
  603.  
  604.      if the threshold value is different.
  605.  
  606.  
  607.           The DO TRAP message for this trap type has the format:
  608.  
  609.  
  610.            Bits   Contents
  611.              0       1
  612.              1       1
  613.            2-3       0
  614.            4-7       0
  615.           8-15       3
  616.          16-31       report identifier
  617.          32-39       occupancy threshold
  618.  
  619.  
  620.      The trap message has the following format:
  621.  
  622.  
  623.             Bits   Contents
  624.  
  625.             0-7    Interface number of Queue.
  626.             8-11   Input(0) or output(1) queue.
  627.             12-15  Above(0) or below(1) the specified occupancy.
  628.             16-23  The occupancy percentage used as a trigger.
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.                                      9
  638.  
  639.